\section{Background}
\label{ch:background}


To better understand the importance of fine-grained resource control in multiplayer gaming let us consider the following scenarios:

\textit{Scenario 1:} A game player X wants to play with more people and would like to face more enemies. He wants to add an option where he can see where more people are playing and he might consider paying extra for this service.

\textit{Scenario 2:} The area where the player is playing at the moment is not enough for him. He might want to join in a bigger area with more missions and different types of challenges.  Bigger world means more in-game objects, entities, NPCs that automatically become a server processing issue and the more resource a server has the more objects it can process in an unit of time.

\textit{Scenario 3:} X did not like the graphics of the game. He bought a new computer with latest gaming hardware and wants to play the game with detail graphics. To understand scenario 3 we have to understand the latency involved drawing each frame on a client machine. There are two types of latency involved. The latency caused by network and the other one is the processing time for maintaining a consistent state of the game. Therefore, replacing with expensive hardware can reduce the network bandwidth and the processing lag thus less time for each response from the server. This allows the graphics hardware on client machine to spend more time on drawing detail frames maintaining smooth graphics.

\textit{Scenario 4:} An online game owner/publisher decided to release new game worlds where new type of enemies and new kind of challenges are available and wants to integrate this game seamlessly as an expansion without changing current state of the game. Here, new game worlds need to be hosted on new servers. Also a game owner/publisher might release the game engine source to third party developers who can develop their own game worlds from where they might be benefited. All of these opportunities are available when we have a fine-grained control over the content of the game as well as resources. 

\textit{Scenario 5:} Consider a game owner/publisher after developing a game decided to release the game API to other third party developers. These third party developers can build new contents of the game (also known as MODs) and release their versions to the gamer community for their own business.

Lot of scenarios can be drawn in the similar fashion. All of the scenarios mentioned above require control over the resources where resources are being sold and bought in an open market. Different policies are developed in the next section that could be a starting point for our research. However the possibilities are not limited to few policies. The policies could be customized according to gamers/developers need.

However, Grid community has done extensive research on this kind of model. Some of the Grid-like infrastructures, for example Emergent Server \cite{rtf-8} or BigWorld \cite{rtf-4}, are restricted to a certain genre, role-playing games(RPGs). Besides, these servers do not allow dynamic creation of new servers through migration for load balancing and for enabling open market MMOG hosting \cite{rtf}. One study \cite{rtf} proposes a framework called Real Time Framework (RTF) to address these issues and supports various distribution concepts like zoning, instancing and replication for challenging action and real-time games. However, no proper studies have been made to provide fine-grained control over the resources and contents.

We divide the resources involved in multiplayer gaming into two broad categories - Game content and hardware resources. We specialize the CyberOrgs model \cite{cyber} for enabling trade in these types of resources. Cyberorgs are distributed resource encapsulations which use eCash to buy and sell resources from/to each other. Contracts are negotiated between Cyberorgs; these
contracts stipulate the types, quantities and costs at which resources would be made available to a buyer by a seller. To specialize the model for our purpose, we replace eCash with real cash, and game content becomes a resource owned by the game publisher/developer. Consequently, gamers are empowered to customize  the kind of game content they want to be entertained with.

To gain better control over the resources, we propose the world of multiplayer game as an open market where four parties own the resources involved. 

\begin{enumerate}


\item \emph{Game owner:} The people including game developers and publishers. The copyright of the game usually belongs to this category. The services provided by this category could be upgrading clients, new gaming options, developing new worlds, keeping up with the change of graphics hardware etc. 
\item \emph{Resource owner:} This category includes owner of the hardware and network resources. Game owners pay the resource owners for their hardware and network resources as well as cost related to maintain these resources.
\item \emph{Game player:} This category includes any non-expert user with a game client, an Internet connection and a game console or computer that is capable of rendering game graphics. Game players receive these entertainment services from game owners and in exchange they pay in real cash.
\item \emph{Broker:} In our work, brokers provide different services to gamers as well as other parties. Any party can register at broker to gain access to the resources or game contents depending on their requirement. Also note that the core game engine does not need to be changed for operating in such an open distributed environment. Broker services may include payment services; registering new resources for resource owners, registering new games or MODs (for developers) and yellow pages services for gamers and game owners to search for new games and resources.

\end{enumerate}

\section{CyberOrgs}
CyberOrgs \cite{cyber} is a model to encapsulate resource and computation. This model allows resource sharing in a network of self-interested peers and an application agent can migrate to a remotely located resource in exchange of a virtual currency called \textit{eCash}. Each CyberOrg contains actors and \textit{eCash}. In this model actors represent computations and a CyberOrg can use its \textit{eCash} to buy resources required for these computations. A CyberOrg can also sell its resources for \textit{eCash} to other CyberOrgs. Actors in the CyberOrg communicate using asynchronous message passing.

CyberOrgs define resources (computational and communication for example) in terms of time and space. A resource is expired at a particular point in time at a particular location if it is not used by some other computation. When a trade happens CyberOrgs requiring resources negotiate with other CyberOrgs for resources through a contract. If a negotiation is successful, a contract is signed between two CyberOrgs and the CyberOrg that needed resources migrates to other host CyberOrg.

CyberOrgs separate concerns of computation and resources through encapsulation. In CyberOrgs ticks are defined as the unit of consumable resource and defined in time and space. For example- a resource R at location L has N ticks available from time T1 to time T2. Every computation requires a certain number of ticks to complete.

In CyberOrgs model, three primitive operations are defined. 

\begin{figure}
\centering
\includegraphics[scale=0.45]{iso-asi}
\caption{Isolation and Assimilation.}
\end{figure}

\textit{Isolation:} CyberOrgs can create a new CyberOrg by using Isolate primitive. This mechanism allows a CyberOrg to collect some of its actors, \textit{eCash} and allows this new CyberOrg to be hosted locally. A contract is also formed between the host CyberOrg and the newly created one.

\textit{Assimilation:} Using Assimilate primitive a CyberOrg can relinquish all of its resources, \textit{eCash} and control to its host CyberOrg and disappears.

\begin{figure}
\centering
\includegraphics[scale=0.45]{mig}
\caption{Migration.}
\end{figure}

\textit{Migration:} Migration is a little more complex than the two other primitives. Each migration is initiated with a contract between two CyberOrgs. A CyberOrg that requires resources for the computations it holds can offer other CyberOrgs to trade resources for \textit{eCash}. Both CyberOrgs can negotiate about the terms of the contract. When the negotiation is successful and a contract is signed host allows the other CyberOrg to migrate and use its resources.

\section{Policies}

Fine-grained control over resources requires significant interactions among different parties involved. Default policies are developed for the users who do not want or need to create new policies. However, policies are customizable to give users more control on the resources. We propose three categories of policies - \textit{gameplay policies}, \textit{resource usage policies} and \textit{payment policies}. 

\textit{Gameplay policies:}
The parties involved in this kind of policies could be game owner/publisher and game players. Users can define new constraints in the policy file to fulfill their requirements. Some policies from owners may enforce gamers or resource providers to agree on some constraints. Using customized policies a user can customize his gameplay requirements and can trade one constraint for another. For example- some users might give up better graphics for better challenges and larger world. On the other hand another user may like to keep all of them. In the same way a game developer can create a policy and advertise a new game world for less price. 

\textit{Resource usage Policies:}
Resource providers can create policies to let the game developers use their hardware depending on peak and off-peak hours. They might want to charge more during peak hours and less during off-peak.

 
\textit{Payment policies:}
Payment policies define how a user or developer can make payment to other parties. Different kind of subscription plan can be used for this purpose. A user might want to use a monthly plan or he might like to use one time subscription. 


Note that as policies are customizable there are plenty of opportunities to create new policies. Each policy has to be negotiated between the parties involved. All policies that are created from successful negotiation and are stored in a repository maintained by the broker. Broker may also create and customize its own policies as it is providing services to others.